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METHOD AND SYSTEM FOR INTEGRATING FEEDBACK LOOPS IN 
MEDICAL KNOWLEDGE DEVELOPMENT AND HELTHCARE 

MANAGEMENT 



CLAIM OF PRIORITY 

[0001] This application claims the priority of U.S. Provisional Application No. 
60/461,105 filed April 7, 2003 and U.S. Provisional Application No. 60/461,526 filed 
April 8, 2003, both of which are incorporated herein by reference. . 

FIELD OF THE INVENTION 

[0002] E-health technologies are enabling a shift in the paradigm of health care fi"om a 
model overly devoted to episodic, crisis-driven care toward a model characterized by 
continuity, crisis prevention, citizen empowerment, and ubiquitous monitoring and 
management of health and Ufestyle factors outside of the traditional patient encounter. 
[0003] This paradigm shift is generating new opportunities and demands to advance and 
disseminate medical knowledge toward truly individualized care, yet new tools are 
needed before such advances can be integrated into clinical practice and be made 
available to citizens. The need for new tools is particularly acute -and the opportunity 
particularly large -in chronic care, where the need for care is increasing due to the aging 
population while the supply of caregivers is declining. 

BACKGROUND OF THE INVENTION 

[0004] This proposal research and develop of a comprehensive new methodology and 
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tool set for medical knowledge management, dissemination, and individualization. The 
research and development activities include (1) development of an ontology and 
semantics engine for medical knowledge and patient information from diverse and 
heterogeneous sources in order to determine best practices and consensus standards of 
care on a continuous basis, (2) development of decision support and knowledge 
dissemination tools in order to generate timely, relevant, and individualized care plans 
and patient education, and (3) development of a continuous feedback methodology and 
system whereby data gathered from the citizen enables care providers to automatically 
individuaUze care plans and patient commimications and medical researchers to 
continuously test and validate rules and associations that drive that individualization. 

[0005] Additionally, tools will be developed to enable researchers to identify patient 
characteristics that correlate to disease progression and outcomes and study of disease 
based on far more detailed patient data, collected at far higher frequency, and on a larger 
scale than was previously possible. The vast new amounts and sources of data, 
particularly high frequency data from ubiquitous monitoring outside of the traditional 
encounter necessitates the development of a new generation of knowledge management 
tools that automate and integrate the collection, processing and dissemination of medical 
knowledge to a greater degree than has previously existed. 

[0006] As these e-health care management tools are disseminated and introduced into 
clinical practice and medical research, it will become possible for care providers, 
patients, and researchers to better understand, predict, prevent, and manage disease. The 
overall goal is to apply and generate medical knowledge in a continuous dynamic 
feedback process that leads to the lowest achievable risk and cost to society and the 
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highest quality of care and quality of life for citizens. 



SUMMARY OF THE INVENTION 

[0007] In one embodiment, a system for processing medical knowledge, includes a 
system a database of medical knowledge sources, wherein an ontology specifies how the 
medical knowledge sources apply to specific disease conditions and patient populations: 
a rendering engine to conyert medical a rendering engine to conyert medical knowledge 
obtained from the medical knowledge sources to a format suitable for a presentation to a 
patient on a selected patient deyice: and a feedback engine to receiye feedback from a 
plurality of patients and to proyide feedback data to the database and the knowledge 
sources. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

[0008] An embodiment of the present invention is illustrated bv way of example and not 
limited in the figures' of the accompanying drawings, in which like references indicate 
similar elements and in which: 

[0009] Figure 1 is an overview diagram of the system, according to an exemplary 
embodiment of the present invention: 

[0010] Figure 2 is a diagram illustrating the system architecture form the viewpoint of a 
Feedback Engine in accordance to an exemplary embodiment of the present invention; 

[0011] Fi gure 3 is a diagram illustrating a Care Management Engine interface with a 

DSTs to provide gap reports in accordance to an exemplary embodiment of the present 
invention: 

[0012] Figure 4 is a diagram illustrating the technology platform in accordance to an 
exemplary embodiment of the present invention: 

[0013] Figure 5 is a user interface diagram illustrating the Inbox of a care provider in 
accordance to an exemplary embodiment of the present invention: 

[0014] Figure 6 is a user interface diagram illustrating the Patient Work List in 
accordance to an exemplary embodiment of the present invention: 

[0015] Figure 7 is a chart diagram illustrating the patient data in accordance to an 
exemplary embodiment of the present invention: 

[0016] Figure 8 is a diagram illustrating the Healthy Buddy device in accordance to an 
exemplary embodiment of the present invention: 
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[0017] Fi gure 9 is a diagrammatic representation of a 3 -Dimensional Model of Disease 
in an exemplary embodiment of the present invention; 

[0018] Figure 10 is a diagrammatic representation of a 4-Dimensional Model of Disease 
in an exemplary embodiment of the present invention: 

[0019] Figure 11 is a diagram illustrating an Information Feedback Loop in accordance 
to an exemplary embodiment of the present invention: 

[0020] Figure 12 is a diagram illustrating an DST Feedback Loop in accordance to an 
exemplary embodiment of the present invention: 

[0021] Figure 13 is a diagram illustrating an Research Feedback Loop in accordance to 
an exemplary embodiment of the present invention: and 

[0022] Figure 14 - 31 are diagrams summarizing one exemplary embodiment of the 
present invention. 
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DETAILED DESCRIPTION 



II Executive Summary 
Proposed Project: 

[0023] In view of the above, MedKnowledgeMent aims to provide the methodology and 
tools for implementing a comprehensive knowledge management strategy in the medical 
environment, with the capability to encompass, classify, process and deliver the 
necessary information at the appropriate time. 
[0024] Figure 1. 

[0025] The proposed project will include- 
/. Information and Knowledge sources- 

[0026] Relationships will be estabUshed with sources of medical knowledge, including 
Universities, Medical Schools, Hospitals, Clinical Laboratories, Primary Care Units, 
Physicians, Care Managers, Medical Research Facilities, medical literature, and other 
sources of medical knowledge. There shall be co-ordination with these sources in order 
to develop the overall system. 
//. Knowledse Acquisition- Knowledge Base: 

[0027] An ontology will be developed for medical knowledge in order to specify how 
medical knowledge sources apply to specific disease conditions and patient populations. 
In this ontology, each disease diagnosis will be associated with a set of representational 
terms covering aspects of care for the condition. Sub categorization under the aspect of 
care will include available treatments, and conditions upon which such treatments are 
used. Based on this ontology, a medical knowledge base will be developed from which it 
will be possible to search for and determine the consensus standards of care based on 
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search criteria. An application program interface (API) and query language will be 
developed to this knowledge base so that other programs can use the knowledge base to 
run queries for specific needs in order to determine and derive consensus standards of 
care in a structured way that can be applied as a rule base a decision support system. For 
example, a care management program could seek information on the consensus standard 
of care for frequency of a particular lab test for a particular disease, as in HbAlc tests for 
a patient with Type II diabetes in a particular age group of patients. Because lab tests for 
particular diagnosis will be part of the ontology for classification of knowledge in 
relation to a disease, the methodology will allow such a query. Research and 
development needs to be done to create a generally applicable ontology and semantic 
network that will allow a scalable classification of knowledge across a wide range of 
disease conditions and populations. Interface to this subcomponent will be an API and 
query language. For this project, care plans will be developed for a range of conditions 
including Chronic Obstructive Pulmonary Disease, Congestive Heart Failure, Type II 
Diabetes Mellitus, End Stage Renal Disease/Transplant, and Depression. 

///, Information Acquisition- Information Base: 

[0028] An ontology and query language will be developed in order to extract data from 
existing clinical infomlation systems including Electronic Health Records (EHR), 
Laboratory Databases, Medical Claims Databases, Genetic and Molecular Biology 
Databases in addition to patient self-reported data that is entered via the Intemet and self- 
care devices. Based on this, an Infomiation Base is generated and integrated in real-time. 
[0029] Semantics Engine will have the capability to integrate patient information from 
multiple sources of Extemal Data, including electronic health records, laboratory data. 
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medical claims data, genetic and molecular biology data. Semantics Engine references 
the data available from the extemal sources, and integrates this data into the patient's 
Information Base through the use of an API. Data is classified in a standard manner to 
allow the extraction of necessary elements to compute risk factors for each of the health 
contexts in the 3-dimensional model of disease for every patient. 

[0030] The Electronic Health Records (EHR) of a patient is referenced, and information 
is extracted by the usage of Natural Language Processing Algorithms. The typical 
information that would be extracted from an ERR includes 

• Patient demographic variables, including name, age, sex, race, national ID 
number, contact information 

• main diagnosis, co-morbid conditions, 

• chief complaints, physical examination findings, 

• family history, 

• lifestyle related factors, such as a history of smoking, alcohol consumption, 
exercise 

• frequency of visits to the healthcare facility, 

• referrals to other health providers, including specialists, co-morbid conditions, 
diagnostic tests ordered, dates of ordering of these tests, and results of the 
diagnostic tests. Included here are the radiological, nuclear medicine 
investigations and functional tests such as exercise stress tests. 
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• prescribed medication, response to medication, development of side-effects, 
especially if the side-effects have necessitated withdrawal of the medication, 
history of admissions, special procedures (such as operations) undertaken, 
indications for the procedure 

[0031] Laboratory Data includes data from a diagnostic laboratory- biochemical, 
pathology, and microbiology, immunological investigations. The data which is of 
primary concern to the system is the date, and type of test, and the test result. The test 
resuhs may be used to schedule additional tests through the use of further protocols. For 
example, if a test value is reported as high, the Care Manager Program institutes an 
intervention, as indicated by the protocol, in addition to scheduling a follow up laboratory 
test to check the effectiveness of the protocol in patient care. 

[0032] Medical Claims Data from the database of an insurer or public health subsidizing 
organization is extracted by the Semantics Engine and complements the data in the EHR. 
Medical Claims Data provides information on the dates and nature of procedures, tests 
and consultations that a patient undergoes. This information is further processed by 
protocols. For instance, the claims data for a diabetic patient may show that the recent 
most visit to an ophthahnologist to be 3 years previously, whereas the standard of care 
requires this to be every 2 years. Care Management Engine alerts the care manager to this 
fact, and a new consultation is scheduled. Semantic Engine correlates the medical claims 
data and EHR in order to prevent duplication of data. 

[0033] Genetic and Molecular Diagnostics Database- Semantic Engine extracts a 
patient's genetic and molecular profile from a Genetics Database, and incorporates this 
inforaiation within Information Base. This is used by Care Management Engine to 
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modify the treatment plan of an individual on the basis of his/her molecular and genetic 
profile. For example, patients with polymorphisms in genes for cytochrome oxidases 
exhibit a different degree of metabolism, and side effects of antidepressants and tests for 
cytochrome polymorphisms may be used to determine the best drug to be used in a given 
patient. Another interesting application is that this data may be used by the research 
engine to correlate subgroups of patients based on treatment response and disease 
outcomes (phenotypic variables) to genetic variations including SNP markers and 
molecular profiles. Many chronic diseases such as diabetes, hypertension, cardiovascular 
disease, obesity, and mental health disorders are thought to have a genetic component. 
IK Information and Knowledge Processins: Decision Support Tools- 
[0034] Queries will be run on Information Base to correlate the extent to which provided 
care is consistent with the consensus standard of care- the Knowledge Base. Decision 
Support Tools (DSTs) will use the results of these queries to generate reports that identify 
potential gaps in patient care. These 'gaps' in care, the difference between hitherto 
provided care and the consensus standard care' is summarized, and presented to 
caregivers, i.e. physicians and care managers. For example, patients with diabetes are 
required by knowledge base to have an HbAlc test every three months. In cases where 
DSTs detects that the last such test has been performed more than this interval, a 
recommendation is given to check if the patient has had an unreported test. If this is the 
case, then the missing test results are entered into the information base. If not, then the 
test is performed. In the interest of patient safety and quality assurance, it is necessary 
that the physician or care manger screens the *care gap' report and confirms that the gaps 
are not due to missing data. 
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V. Information and Knowledge Renderins: Renderine Ensine- 

[0035] Dialogues and health content is rendered for presentation, by a Rendering Engine 
that converts the data into a format which may be interpreted by different types of 
devices including Personal Computers connected to the Intemet, interactive Television, 
Personal Digital Assistants, and remote health appUances, such as the Health Buddy TM 
apphance that are used by a patient to communicate with the system. Conversely, 
Rendering Engine converts patient repUes to dialogs, and biometric measurements from 
different devices into the standard system format. 
VL Information and Knowledge Acquisition: Feedback Engine- 
[0036] The Feedback Engine is of key importance in the knowledge management cycle. 
Feedback Engine will enable a regular and ongoing interaction between the patient and 
the care manager, physician and researcher, outside of the clinical encounter. Feedback 
Engine will interface with DSTs using Application Program Interfaces, to generate 
personalized recommended 'care plans' based on the patient's updated Information Base 
and disease Knowledge Base. Care plans will be forward looking and will recommend 
steps for monitoring and managing patients along a future timehne. The structure of the 
monitoring and management plan is based on the characteristics- symptoms, behavior 
(i.e. treatment compliance), knowledge and test results matched to medically relevant 
aspects of care. The plan will include monitoring, management and follow-up directly 
with the patient and reporting to the care manager. This is an intervention that would be 
implemented using eHealth technologies for frequent dialogues with the patient over a 
network. It will also include a customized health education plan. Caregivers, i.e. 
physicians and care managers decide, in consultation with the patient the future course of 
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action, with regard to the recommended care plan. In the first iteration of the patient 
monitoring and management plan, the plan is based on the personalization of a pre- 
packaged care plan designed for the specific medical condition of the patient. 
Subsequent iterations will allow for progressively greater customization and 
individualization of plans to the information base. Feedback Engine will allow the 
system to correlate and analyze data within Information Base and Knowledge Base and 
apply these analyses to make new discoveries and fiirther the growth of medical science. 
[0037] Feedback Engine will consist of three components - 
[0038] Figure 2. 

[0039] a. Dialogue Engine - Dialogue Engine maintains ongoing patient interaction that 
is individualized to the patient. It sends dialogues (content) to the patient for display on 
the commxmication device. Dialogues include medical advice to the patient, educational 
materials, and queries to a patient regarding his/her medical condition. Dialogues can 
also be script programs instructing the Biometric Device to collect physiological 
measurements of the patient. Dialogues are generated using Information and Knowledge 
Base. Dialogues Engine interfaces with the Rendering Engine in order to customize the 
dialogues to the specific type of communication and biometric devices used by the 
patient. Replies to dialogues, and measurements fi-om Biometric Devices are fed back 
into the Information Base. 

[0040] b. Care Management Engine - The individual patient data resulting from the 
monitoring and management plan will be fed back into the Information Base, where it 
becomes a part of the patient record that is used in subsequent iterations of the 
Information and Knowledge Processing System to generate an increasingly 
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individualized care plan with as the knowledge base grows and increases in its precision. 
This will allow the patient care plan to attain a greater degree of patient specificity and 
individualization with the passage of time, as the system has a better perspective of a 
patient's specific needs. As the research and development in this project refines the 
methodology and semantic network for sharing medical knowledge, the feedback loop 
will be enhanced to enable a transition from personaUzed 'prepackaged programs' to truly 
patient specific 'individualized programs'. Care Management Engine may also interface 
with DSTs in order to provide gap reports, as shown in the figur e Figure 3 below. 
[0041] Figure 3, 

[0042] c. Research Engine - The data aggregated fi-om the original patient profile in 
combination with the longitudinal data created from the patient monitoring and 
management plan will be aggregated across the entire population of patients in the 
system. Such data will be bUnded and no individually identifiable characteristics will be 
retained. The research engine tool set will enable a researcher to perform a query on a 
patient population and to identify subgroups of that population with different 
characteristics. With these clusters, the researcher will then be able to search for any 
other variable with meaningful correlation to the respective clusters. Examples of 
searches that will be performed include identifying subgroups of patients who respond 
differently to a pharmaceutical treatment regimen, and then to identify other 
characteristics that correlate with the sub grouping in outcomes. Examples include 
patient behavior, environmental variables, and gene variation. The goal is to enable 
academic research to identify characteristics that predict disease progression and 
complications so that standards of care can be further individualized and the knowledge 
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base will be continuously enhanced. 

[0043] One particularly interesting use of the research engine is specifically to correlate 
subgroups of patients based on treatment response and disease outcomes (phenotypic 
variables) to genetic variation. Many chronic diseases such as diabetes, hypertension, 
cardiovascular disease, obesity, and mental health disorders are thought to have a genetic 
component. The current effort uncovering single nucleotide polymorphism markers 
(SNPs), representing the common variations among the DNA of individuals, holds 
promise of understanding the genetic basis of chronic disease and related drug response 
(pharmacogenomics). The problem, however, remains that complex disease may have 
multiple etiologies, and the interaction of muUiple genes with behavioral and 
environmental factors may underlie chronic disease occurrence and progression. This 
project will assess the feasibility of conducting genetic epidemiological research using 
longitudinal patient data on phenotype and environment variables collected through 
patient monitoring and management plan in a population of patients. The goal will be to: 
(1) develop a program that monitors phenotype and environmental variables for a specific 
set of diseases; (2) work with a clinical site to collect daily data from patients; (3) 
quantify phenotype and environment variability in sub-populations stratified by genetic 
factors; (4) develop linkages to life sciences projects capable of collecting and analyzing 
serum sample for genotyping; and (5) develop statistically appropriate design/analysis 
methods for assessing phenotype- genotype-environment associations. 

m Project Aims: 

[0044] 1. Research And Development Phase (0-24^^ month) 
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To develop a multi-dimensional model of disease and representative form of a 
patient's disease state; and to link the ongoing longitudinal monitoring to 
model, in terms of risk expression and aspects of care. Further, to structurally 
relate Knowledge Base and Information Base to the multi-dimensional model, 
which will enable the other objectives of the system. 

To create the required content including patient queries and dialogues, and to 
categorize it by key aspects of patient care, in order to ensure a holistic 
approach towards patient care. 

To develop a Dialogue Engine that will individualize medical management to 
the patient, and will allow the patient to be ubiquitously monitored, between 
clinical encounters, and in a manner that fits into his/her lifestyle. To link 
Dialogue Engine with Rendering Engine to ensure content presentation on an 
entire range of devices, and greater patient connectivity. 

To develop a Care Management Engine that automates content assignment on 
the basis of Information Base of a patient and Knowledge Base of the disease. 

To develop a Research Engine that permits researchers to identify subgroups 
and correlates of individuals with unique variables in their profile that set 
apart their condition from the rest of the individuals; and to test hypotheses on 
this database of individuals. 

To link remote care systems to Decision Support Tools, that will enable a 
paradigm shift from current manual processes and methods of risk 
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stratification to automated individualized care; which will additionally 
optimize caregiver time, and enhance productivity. 

• To develop an open interoperability standard for all components of the 
system, including Knowledge base, Information base, Decision Support 
Tools (DST) and Rendering Engine. 

• To test the interoperability between Feedback Engine, Knowledge Base, 
Information Base, DST and Rendering Engine, and its compatibility other 
Integrated Project components, with currently used systems (including 
communication systems), and with extemal data systems, including legacy 
database systems. 

[0045] //. Validation Phase (25- 4Sf^ month) 

• To apply the system in the management of chronic health diseases in a 
demonstration project in multiple centers across Europe, in a randomized control 
study. 

• To compare outcomes of disease managed by the system vis-a-vis that managed 
by present means, and aggregate data analysis for global impact. Outcomes 
analyses include health outcomes, cost-savings. 

• To measure the impact the remote health management system has on certain key 
measures including: patient acceptability, satisfaction, utilization, clinical impact, 
medication compliance, quality of Ufe, cost of care 

• To conduct site specific data analysis by country, disease, and care model. 

• To assess the feasibility of conducting genetic epidemiological research using 
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longitudinal patient data on phenotype and environment variables collected 
through patient monitoring and management plan in a population of patients, 

I¥ State Of The Art: 

[0046] Health Buddy and the iCare Desktop web service from Health Hero Network is a 
chronic care management solution that enables care providers to remotely monitor 
patients and detect problems early, while supporting daily patient education and treatment 
compUance. The Health Buddy appliance was introduced 1999 in the US and in 2003 in 
Europe. Over thirty care provider sites are currently monitoring 2,500 chronic patients 
everyday, and over two million patient surveys have been taken to date. Sites where the 
disease management solution has been implemented include Veterans Health Affairs, 
Mercy Health System and Kaiser Permanente in the United States, Implementation is in 
process at Universite Louis Pasteur (ULP), Strasbourg, France as a part of post-transplant 
care management program, and 150 patients are expected to be enrolled in the program in 
2003. Additional implementations in process in Europe through agreements with Abbey 
Healthcare Ltd (Lreland) and Sananet B.V. (Netherlands). 

[0047] Currently available programs include heart failure, coronary artery disease, 
diabetes, asthma, COPD, hypertension, and mental health, in addition to custom 
programs authored by care providers such as for post-transplant care and obesity. 

Current T e chnology 
The Technology: 

[0048] The Health Hero platform consists of a series of web-based applications anchored 
by the Health Hero® iCare Desktop™ and a series of patient interfaces. The primary 
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patient interface, the Health Hero HeaUh Buddy® is an easy-to-use information appliance 
placed in the patient's home. Health Hero provides other patient interfaces such as Health 
Buddy Web, for intemet-sawy patients, and are in development stages for patient 
interfaces based on mobile technologies and interactive television. The web applications 
and patient interfaces combine to form a secure infrastructure that links providers to their 
at-home patients while supporting a flexible, cost effective means for daily monitoring. 
[0049] Figure 6. 

[0050] /. Health Hero iCare Desktop 

[0051] The Health Hero iCare Desktop appHcation provides secure access to a series of 
web- based tools specifically designed for the patient management and workflow needs 
of a care provider. The iCare Desktop's capabilities include analysis of patient responses 
and alerts, review of patient trend data, and production of patient reports. The key feature 
of the iCare Desktop experience is that it enables care providers to quickly review the 
status of a large population of patients, which is also what differentiates it from other 
standard clinical information systems. The review process makes it possible to identify 
the patients in need of attention or follow-up based on a set of subjective and objective 
data points giving a total view of the patient's daily health status. 

[0052] A care provider uses the iCare Desktop to view patient responses and identify 
responses within a patient population that are stratified as high, medium or low risk in the 
categories of symptoms, behaviors, and knowledge. This information is used to quickly 
assess which patients need an intervention on any given day. Care algorithms, Standard 
Operating Procedures (SOPs) and/or standing orders from the patient's physician guide 
the intervention. The Health Hero platform collects data that allows care providers to 
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make clinical decisions based on longitudinal data, rather than a single telephone call or 
data point. 

[0053] The efficiencies of the Health Hero Platform are realized through the improved 
data collection capabilities of the Health Buddy appliance and through the workflow 
features of the iCare Desktop. Disease management programs with care managers using 
the Health Hero Platform have more than double the number of patients previously 
managed using a manual approach to disease management. 

[0054] Two specific features that greatly enhance workflow are the Inbox and the Patient 
Work List. These features provide two different views of patient results, allowing a care 
provider to deal with events as they happen using the Libox, or in a more detailed manner 
with the Work List. 

[0055] The Inbox feature of the iCare Desktop collects alerts, high risk and medium risk 
events in an interface similar to email software. As events are uploaded to the platform, 
the Inbox automatically creates a "to-do" list of critical tasks for each care provider's 
patient population. The items are classified by the standards of care and risk levels 
stipulated by the patient's care providers. 

[0056] The care provider is presented with a category and a subject for each Inbox event, 
describing the results. A typical care provider workflow would consist of scanning the 
Inbox for results, and either clicking on the date to review the detailed results data, or 
using the check box to mark that the patient results were reviewed. 
[0057] Figure 5. 

[0058] Whereas the Inbox collects a subset of patient results in a to-do Hst fashion, 
independent of the date and time, the Patient Work List is designed for review of a 
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population in 24-hour time periods. This view provides the ability to quickly review the 
health of a population and determine which patients still require further assessment. 
[0059] The Patient Work List provides options for how the patient results are reviewed. 
A care provider is able to adjust both the time period of results and the disease programs 
of patients to displayed.. Supervisors and other iCare Desktop users with the correct 
permissions can also examine the Patient Work Lists of other care providers for quahty 
control and "out of office" coverage. 

[0060] A common question asked by those responsible for the management of a large 
population of chronically ill patients is, "How do I know I served all the patients who 
needed care under my SOPs?" The Patient Work List addresses this problem in real-time 
through the use of a graphical indicator to display the review status of each resuh. 
As shown in Figure 6 ^, each row of the Patient Work List includes a circular review 
indicator. A full circle indicates that the results have been reviewed by the care provider 
currently looking at the Work List. A half-filled circle indicates that another member of 
the care team reviewed the result. An empty circle indicates that the result has not been 
reviewed. This "at-a-glance" interface allows care providers to quickly confirm that an 
SOP has been followed when appropriate. Full audit logs of the review and disclosure of 
patient results, including the reviewer name, time and date of review, and method of 
review are logged and maintained by the Health Hero platform. 
[0061] Figure 6. 

[0062] Care providers have access to patient data collected over time through the trend 
chart pages, which are graphical representations of the patient data. Analysis aids, such 
as baseline weights and target goals, can be displayed on the trend charts to provide 
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guidelines for review. 
[0063] Figure 1. 

[0064] Teams of care professionals provide the highest quality patient care and all 
members of the care team must be able to access clinical information for each patient in 
the manner that is the least disruptive to their existing workflow. The iCare Desktop 
provides robust reporting tools that faciUtate the faxing, emailing, and printing of reports 
for review outside of the iCare Desktop workflow. 

[0065] For those members of the care team who choose to use the web-based tools for 
patient management, the iCare Desktop is designed with role-based permissions, so each 
individual contributor to the patient's care is able only to interact with the specific patient 
data that is required to complete their professional function. 

[0066] Providers access the iCare Desktop from a personal computer with an Internet 
connection. The iCare Desktop requires no installation of software or hardware, and 
little-to-no staff support from provider Information Technology (IT) groups. System 
maintenance, backup, and security is managed by Health Hero Network and it's 
networking partners. 
[0067] //. Health Buddy® ApDliance 

[0068] The Health Buddy appliance, shown in Figure 8 5, serves as the primary patient 
interface for secure communication between patients and the network. The Health Buddy 
was designed as an easy-to-use communication appUance for placement in the patient's 
home, and has gone through significant commercial validation as a welcome in-home 
healthcare tool. 

[0069] The ease of use begins with the Health Buddy installation process, which is most 
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often conducted by the patient with no assistance. The Health Buddy requires a standard 
telephone outlet and standard power outlet, and requires no additional telephone lines, 
software, or computer experience. When power is applied, the Health Buddy presents the 
patient with an interactive Health Buddy tutorial, and then within one hour of taking the 
tutorial, the patient receives their first Health Buddy survey. 

[0070] The Health Buddy provides the patient with at least one survey per day. The 
surveys are designed to enable patients to easily respond to a range of questions, that 
relate to important aspects of care for their specific condition. Once the patient answers 
the questions in the survey, the Health Buddy stores and transmits the information back 
to the care providers, who will review the data using the iCare Desktop. Although the 
standard model of care for patients uses a once-per-day survey transmission mode, the 
transmission of results can be customized to upload patient data at any desired frequency, 
including in response to a particular patient result. 
[0071] Figure 8. 

[0072] The Health Buddy is intended to gather quantitative and quahtative patient 
information through a simple question, answer and education session. In some cases, it is 
important to augment quantitative and self-reported qualitative data with information 
collected directly fi^om medical devices. The Health Buddy appliance, through the 
Buddylink™ feature, allows the collection of data from medical devices, such as blood 
glucose meters, weight scales, and blood pressure cuffs. The objective data is collected 
during the survey process so that the patient still benefits from the education, behavior 
modification, and personalized responses. 

[0073] The benefits of employing the Health Buddy and the iCare Desktop web service 
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in disease management have been validated in articles published in several peer-reviewed 
journals. Briefly, the Health Hero Disease Management Programs have shown clear 
benefits over other programs, in terms of- 

[0074] Cost Benefits: Health Buddy reduces hospital admissions and costs by detecting 
problems before they become a crisis. A recent study at the Veterans Health Affairs 
reported a 60% reduction in hospital bed days of care in a one year trial with 791 CHF, 
COPD, diabetes, and hypertension patients in a chronic care program in which most 
patients were monitored daily using Health Buddy. Similar cost savings were reported in 
Medicare HMO patients. (Meyer et al, Disease Management 2002; 5: 87-94. Vacarro et 
al, Disease Management 2001; 4(3): 1-10.) 

[0075] Access to Care: Health Buddy increases access to care by expanding the capacity 
of care providers to monitor patients using existing resources. Through daily 
communication, patients are able to access timely care before conditions become a crisis. 
At Mercy Health System, a part-time nurse provides daily monitoring for 425 heart 
failure, diabetes, and hypertension patients. With telephone-based monitoring only, a 
full-time nurse could provide weekly monitoring to less than 100 patients. The efficiency 
achieved through Health Buddy allowed for coverage of uninsured patients who 
otherwise would have received no care at all. (Cherry et al, Diabetes Technology & 
Therapeutics; 4(6): 793-791.) 

[0076] Oualitv of Care: H ealth Buddy improves quality of care by providing timely, 
relevant, and actionable information to healthcare providers so that care can be 
coordinated in a quality assured process. Care providers are able to detect complications 
before they become acute and result in hospital admissions, providing quality care that 
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reduces painful and costly complications by maintaining patients in a healthier state. 
Health Buddy also improves patient outcomes by improving treatment compliance 
through educating, motivating and monitoring patients daily. (Cherry et al, Lippincott's 
Case Management 2000: 5(5): 191-198. Guendelman et al, Archives of Pediatric and 
Adolescent Medicine 2002: 156: 114-120.) 



Scope For Innovation: 





State of the Art 


Scope of Innovation 


Patient 

Dialogue 

Engine 


Pre-packaged, mass 

customized 

programs 


Automated individualization of programs 


Content Libraries 


Content Generated by knowledge base rules 
applied to information base 


Health Buddy 


Interface to Rendering Engine for any device 


Care 

Management 
Engine 


Risk Stratification 


Intelligent risk tuning and link to DST 


Organized 
workflow and 
efficiency tools 


Organizational optimization 


Manual feedback 
process 


Automated feedback loop 


Research 
Engine 


Data Export to S AS 


Identify subgroups and correlations 




Test hypotheses on living database 



Table: The contribution of Feedback Engine in terms of innovation 



VIr Multi-dimensional Model of Disease: 
[0077] L The 3-dimensional model of disease 
[0078] Figure 9, 

[0079] The above diagram illustrates a three dimensional model of disease. In this model, 
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a patient's health at a point in time is determined on a relative risk scale. The Y-axis 
contains slabs, each relating to a specific aspect of care. For instance, in a multi-system 
disease like Diabetes, one slab relates to blood glucose control, another to the 
cardiovascular system, still others to foot care, the neurological, renal and ophthalmic 
systems. Given the complex multiple interactions between different aspects of care, there 
may be occasional overlap between different slabs. For instance, glucose control, when 
applied in the long-term sense, is related to the cardiovascular, renal and most other 
systems. In such cases, each factor of interest is represented separately and 
independently on the Y-axis. 

[0080] Each aspect of care in the individual patient is further modulated by a patient's 
knowledge of disease (in that aspect of care), patient behavior, signs, symptoms, test 
results, and general resistance to medical advice. Each such aspect of risk expression is 
represented in the model on the Z-axis. A specific aspect of care (Y) for a specific 
expression of risk (2) is termed a 'health context'. The X-axis relates to the relative level 
of risk exhibited by an individual patient for each health context. Lower x values of a 
patient indicate a better state of health. 

[0081] For example, in case of blood glucose control in diabetes, the actual behavior of 
the patient, and disease outcomes are a function of the 

1 . Patient's knowledge- a patient with a greater knowledge (lower risk) of the long- term 
complications of diabetes, and its relationship to blood glucose control is more likely 
to be compliant with the diabetic diet and regimen (better outcome). 
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2. Behavior- Humans exhibit varying behaviors regardless of the level of knowledge of 
their disease condition. Some individuals are more health conscious (lower risk) than 
the others. 

3. Signs, Symptoms, and test resuUs-. A patient whose blood glucose values are 
consistently within the normal range (lower risk) gets the requisite positive feedback, 
encouragement, and impetus to further adhere to the prescribed medical regimen. 
Conversely, patients who develops complications of medication, such as nausea, 
vomiting or hypoglycemic attacks are at a greater risk of being non- compliant with 
medical advise. 

4. Follow-up, compliance, and Resistance- On continued follow-up, one or more of the 
above factors may change. For instance, as a patient's knowledge of his/her disease 
condition increases, he/she may be more inclined to be compliant with the medical 
regimen. Resistance is defined as the tendency of patients to resist medical care and 
the changes it entails with regard to one's Ufestyle and habits. In the context of the 
disease model, resistance is additionally related to a patient's perception of the value 
of medical regimens. 

[0082] The Fourth Dimension: Time- The three dimensional model is 'static', in that it 
doesn't describe the changes that take place in the patient's disease state with time, nor is 
it descriptive about the effects of various interventions and medical therapies on the 
Liformation Base. To this end, the fourth dimension of time is added to the three- 
dimensional model. The aim of disease management is to achieve the lowest overall risk 
in a group of patients. 
[0083] Figure 10. 
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[00841 It permits outcomes analysis to be perforaied. Additionally, it allows one to study 
(and test) effects of multiple expressions of risk and aspects of care with regard to one 
another, as a function of time, in a single patient. 

[0085] //. Description of system components in relation to the multi'dimensional model 
[0086] Knowledge sources and medical Uterature typically supply recommendations as to 
'standard of care* in the form of care management algorithms. However, these algorithms 
would need to be interpreted and applied into the system by Decision Support Tools and 
Care Management Engine. Further, the format and logic would need to be common for 
all the system sub-components, in order that interfacing is made possible by the use of 
Application Program Interfaces. Finally, the logic has to be mapped to the multi- 
dimensional model of disease. The proposed system architecture, type, nature, and 
format of data exchange between the system's components will be better understood 
when explained in reference to standard care management algorithms. One such 
algorithm, specifically an algorithm relating to the management of patients with 
congestive heart failure by Care Managers is given in the table below- 
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TITLE: 



CONGESTIVE HEART FAILURE SURVEILLANCE DURING DIURETIC ALGORITHM 



POLICY 



1. Function: 

To outline the nursing management of patients who are referred by their physician to Health Buddy 
Congestive Heart Failure Program. Registered nurses independently titrate the patient's regularly 
prescribed diuretics and potassium based on the patient's symptoms and weight gain using an 
approved algorithm. 

Circumstances under which the RN may perform this function: 

Registered nurses who work in Health Buddy Congestive Heart Failure Disease Management 
Program may initiate this standardized procedure when directed by the patient's physician. 
Patient contraindications to use of this standardized procedure include pulmonary edema, new or 
refractory chest pain, new or sustained arrhythmia, syncope. 



PROTOCOL 



1. Definition -The Health Buddy Congestive Heart Failure Disease Management Program is an 

outpatient-based approach to managing chronic CHF patients, where Registered Nurses provide 
education, support, and clinical follow-up to patients with congestive heart failure under the 
direction of a Physician. 

2. Assessment -Assess patient for signs and symptoms of worsening congestive heart failure 

• Breathlessness, paroxysmal nocturnal dyspnea, orthopnea, dyspnea at rest 

• Weight gain 

• Edema 

• Compliance with medication regime 



PROCEDURAL STEPS 


KEY POINTS 


1. Once a change in status has been indicated, 
interview patient via telephone to verify the patients 

status. 

2. Interview patient to determine subjective complaints 
of SOB, fatigue and other signs & symptoms of 

CHF. 

3. Based on the patients subjective symptoms and 
current weight, implement the folloMdng. 


Total daily doses of diuretics should not exceed the 
following limits unless approved by physician: Lasix 240 
mg, Bumex 10 mg, Metolazone 5 mg, Demadex 240 mg. 


Patient's Symptoms 


Weight 
Gain in 
Pounds 


Treatment 
Category 


Treatment Legend 


No new symptoms 


1-2 


Restrict Salt 


1 = Extra dose of the patient's regularly prescribed diuretic 
and potassium now*. 

2 = Extra dose of the patient's regularly prescribed diuretic 
and potassium now, then an extra daily dose for 3 days*. 
Daily phone calls from Health Buddy nurse. Obtain renal 
panel within 48 hours if current creatinine >1 .8. 

3 = Double dose of the patient's regularly prescribed 
diuretic and potassium now, then an extra daily dose for 3 
days*. Health Buddy nurse will notify patienfs primary 
physician. Obtain renal panel within 48 hours if 




3-4 


1 




>4 


2 


New or worsening 
paroxysmal nocturnal 
dvsonea 


1-2 


1 




3-4 


3 




>4 


3 


Orthopnea 


1-2 


2 




3-4 


3 




>4 


3 


Shortness of breath when 
seated 


1-2 


2 
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3-4 


3 


current creatinine> 1.8. 

4 = Double dose of the patient's regularly prescribed 
diuretic and potassium now and again in 4 hours*. Health 
Buddy nurse will notify patient's primary physician; office 
visit scheduled. Obtain renal panel (if current creatinine 
>1 ,8) and Mg-H- within 48 hours. 

5 = Refer to emergency department. Health Buddy nurse 
will notify physician and appropriate emergency 
denartment 




>4 


4 


Pulmonary edema refractory 
to treatment category 4, 
chest pain (new or 
refractory to nitro), 
arrhythmia (new or 
sustained), syncope 




5 


4. To manage the patient who loses weight below their 

pre-determined dry weight: 

2-3 pound weight loss- halve diuretic for one day; if 
recurrent, reduce to half dose every other day.* 

4-6 pound weight loss -reduce diuretic to half dose 
daily, obtain renal pane*, and notify physician. 

7 or more pounds -hold diuretics, obtain renal panel*, 
and notify physician. 


*Essential to reduce potassium supplements an equivalent 
amount. 


5. To manage the patient with excessively rapid weight 
loss: 

3-5 pounds in 24 hours** ~ confirm appropriate 

potassium replacement 

Weight loss of more than 5 pounds in 24 hours* *~ 
confirm appropriate potassium replacement, obtain 
renal panel, and notify physician. 


**If weight loss continues longer than 24 hours, obtain 
renal panel and notify physician. 


7. Follow-up phone calls from Health Buddy nurses are 
required for treatment categories 2, 3,4, and 5 and for 
all patients with weight loss below dry weight and 
excessively rapid weight loss within 72 hours of 
initiating the treatment change. 


The primary physician must be consulted if the patient 
meets criteria for emergency department referral, weight 
loss below dry weight of 4 or more pounds, and 
excessively rapid weight loss of more than 5 pounds in 24 
hours. 



Table: A health context management algorithm 



[0087] Kxiowledge Base: K nowledge Base, the summation of medical knowledge and 
concepts is organized by location pointers, expressions that define the location of any 
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aspect of disease on the multi-dimensional model, and protocols, which are logical 
expressions that define the relationships between the health contexts, and the actions that 
need to be taken for possible combination of factors within the health context. Within the 
multi- dimensional model of disease, location pointers are represented on the X, Y - and 
Z-axis. Every possible piece of information that is collected by the system is mapped on 
to the 3- dimensional model. 



[0088] hi the above example, 



DIRECTIONAL POINTER: CHF SURVEILLANCE 


DISEASE: 


CONGESTIVE HEART FAILURE 


ASPECT OF 
CARE: 


DIURETIC MANAGEMENT 


KNOWLEDGE: 


OF 

ORTHOPNEA 


YES 


NO 






OF 

PAROXYSMAL 

NOCTURNAL 

DYSPNEA 


YES 


NO 




OF 

NECESSITY 
TO RESTRICT 
SALT 


YES 


NO 


OCCASIONALLY 


BEHAVIOR: 


EXERCISING 
REGULARLY 


YES 


NO 


OCCASIONALLY 


RESPONDS TO 

HEALTH 

BUDDY 


YES 


NO 


OCCASIONALLY 


RESPONDS TO 
PHONE CALLS 


YES 


NO 


OCCASIONALLY 


SIGNS: 
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SYMPTOMS: 




NO NEW 
SYMPTOMS 


NEW OR 

WORSENING 

PND 


ORTHOPNEA 


TEST 
RESULTS: 


WEIGHT GAIN 


1-2 LB 


3-4 LB 


>4 LB 


CREATININE 


<VALUE> 






WEIGHT 


<VALUE > 






K+ LEVEL 


<VALUE> 






COMPLIANCE: 


COMPLIANCE 

WITH 

MEDICATION 


GOOD 


MODERATE 


POOR 


COMPLIANCE 
Wlln DlJil 


GOOD 


MODERATE 


POOR 


FOLLOW UP: 











[0089] Thus, Knowledge Base defines the location of the particular attribute on the 
model. It is common to all patients with a single disease. Further, the 'risk-states' that are 
given to a particular variable is defined at the time of creation of the model For 
example, in the health context of Behavior (Responds to phone calls), a value of 'Yes' 
will lie towards the low risk end of the X-axis, while, a value of 'No' will lie towards the 
high risk end. For continuous variables, for example, the results of a laboratory test, or 
Creatinine values, the value of a health context is represented as such, on a scale. In case 
where a low value is medically significant, such as a low serum potassium value, it is 
represented by two contexts, one for hypokalemia (low potassium) and another for 
hyperkalemia (high potassium values). On the contrary, if low values of a measurement 
have no medical significance, for example Creatinine value, then it is represented by a 
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single context. 

[0090] In order to automatie patient care, and to achieve the other objectives of the 

system, it is necessary to incorporate into the system, the logic that will enable it to 

decide on a course of action to be taken, or a treatment plan, which are the Protocols. 

Protocols tell the system the action that needs to be taken for any of a combination of 

unique variables in the Information Base. Protocols are the 'threads' or connections that 

link the discrete data components that ultimately forms the Information Base. 

[0091] In the above context, 

PROTOCOL: DIURETIC PRESCRIPTION 

IF SYMPTOMS = 'NO NEW SYMPTOMS' 

AND WEIGHT GAIN = ' 1-2' 

THEN ACTION: RESTRICT SALT 

IF SYMPTOMS ='N0 NEW SYMPTOMS' 

AND WEIGHT GAIN = '3-4' 

THEN ACTION 1 . : INCREASE_DOSE_DIURETIC 

THEN ACTION 2: GIVE PATIENT POTASSIUM 

IF SYMPTOMS = 'NO NEW SYMPTOMS' 

AND WEIGHT GAIN = '>4' 

THEN ACTION 1 . : INCREASE_DOSE_DIURETIC 

THEN ACTION 2: GIVE PATIENT POTASSIUM FOR 3 DAYS 

THEN ACTION 3: ALERT CARE MANAGER: TO PHONE PATIENT 

THEN ACTION 4: OBTAIN RENAL PANEL 



[0092] Information Base- This is individual to a patient, and is created in response to the 
data (responses to queries), measurements of the patient, and external data sources. In 
the 3 dimensional model of disease, a new 3 -dimensional model is created for each new 
piece of information. In general, the information base provides a health profile of the 
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individual at that point of time, and is sufficient for deciding the care management, when 
used in reference to Knowledge Base. The table below depicts the Information Base of a 



particular patient at a point in time. 



PATffiNT NAME: SCOTT, JANE 


DISEASE: 


CONGESTIVE HEART FAILURE 


DATE, TIME 


9 APRIL 2003, 1400 HRS, GMT 


KNOWLEDGE: 


OF ORTHOPNEA 


OF 

PAROXYSMAL 

DOCTURNAL 

DYSPNEA 


YES 






OF 

NECESSITY 
TO RESTRICT 

Q AT T 


YES 






BEHAVIOR: 


REGULARLY 






OrCASTONALLY 


RESPONDS TO 

xjp A T TFT 

BUDDY 


YES 






RESPONDS TO 
PHONE CALLS 






OCCASIONALLY 


SYMPTOMS: 




NO NEW 
SYMPTOMS 


NOW OR 
WORSENING 


ORTHOPNEA 








PND 




TEST 
RESULTS: 


WEIGHT GAIN 




3-4 LB 




CREATININE 


1.7 






WEIGHT 


149 LB 






K+ LEVEL 


4.4 






COMPLLWCE: 


COMPLIANCE 
WITH 

MEDICATION 


GOOD 






COMPLIANCE 
WITH DIET 




MODERATE 
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[0093] However, in some cases, current Information Base alone is insufficient in 
deciding the course of management of the patient. Previous or baseline values are 
required for comparison. This is especially the case where the laboratory values are used. 
For example, in this patient with Congestive Heart Failure, a weight of 65 kg, has no 
meaning in itself, unless it is compared with the patient's previous weight. A weight gain 
could be the first sign of fluid accumulation and impending heart failure. 
[0094] Serial follow-up of Information Base has immense Research utility, for example 
in outcomes analysis, and in con-elating the effects of a new drug or intervention on an 
entire range of patient variables. 

[0095] Decision Support Tools- Decision Support Tools determine the extent to which 
provided care is consistent with the consensus standard of care. For example, in 
Diabetes, knowledge base protocols will require that the patient has a HbAlc test every 
three months. The following protocol logical expression is applied to determine if the 
standard of care has been followed. 

PROTOCOL 

IF [DATE (TODAY) ] - [DATE (HBAIC-TEST)] > 90, 
THEN 

DOACTION: INFORM CARE MANAGER (PATIENT) 

[0096] The following protocol 'tells* the Decision Support Tools the effects that a 
particular intervention has on the risk factor levels of different health contexts. On 
increasing the daily injected insulin dose, the risk of developing hypoglycemic episodes 
is raised significantly, also there is a risk of weight gain and an increased cost of 
medication to the provider. Finally, the biometric device is scheduled to receive three 
blood glucose samples for a week. 
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IF INTERVENTION (INCREASE INSULIN DOSE) = ^TRUE^ 

THEN RISK (HYPOGLYCEMIC EPISODE) = RISK + (VARl) 

ALSOTHEN RISK (WEIGHT GAIN_NEAR TERM) - RISK + (VAR2) 

ALSOTHEN (MEDICATION COST) = (MEDICATION COST) -f (VAR3) 

ALSOTHEN DO (TEST_GLUCOSE_VALUE) = 3TIMES/DAY * 1 WEEK 

[0097] In deciding the course of management of the patient's condition, DSTs reference 
the Information Base and the Knowledge Base. 

¥Ifc Feedback Loops: 

[0098] The Feedback Engine will enable a regular and ongoing interaction between the 
patient and the care manager, physician and researcher, outside of the clinical encounter. 
There will be three main types of feedback loops- the Information Feedback Loop, the 
DST Feedback Loop, and the Research Feedback Loop. 

[0099] The Information Feedback Loop- The Information Feedback Loop provides 
feedback to the Information Base. It is the feedback loop from the perspective of a 
patient, enabling individualized communication, and ubiquitous monitoring of a patient. 
Updates to the patient Information Base are made automatically, and in real time, thus 
allowing for reduced latency from the provision of information to action taken. 
Dialogues are not only customized to comprehensive and updated information, but also 
are rendered for output in a variety of formats. 
[00100] Figure IL 

[00101] In the first step. Dialogue Engine links to Knowledge Base and Information 
Base in order to create and select dialogues that are most suited to the patient's 
Knowledge Base and Information Base. In the next step. Dialogue Engine interfaces 
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with Rendering Engine to format the dialogues for transmission and uptake by the patient 
communication device and biometric device. Query dialogues are sent to the 
Communication Device, for display to the patient. Additionally, Dialogues are sent to the 
Biometric Device, either directly, or via communication device with commands to collect 
measurements of physiological variables. Replies of the patient and measurements from 
biometric devices are re-routed to the Dialogue Engine through the same commimication 
system. The Dialogue Engine further interfaces with Rendering Engine, in order to 
interpret the signals, and appends the newly collected data to the Liformation Base. The 
updated Information Base is in tum used in subsequent iterations of the patient 
management process. 

[00102] DST Feedback Loop - The DST Feedback Loop provides feedback to Decision 
Support Tools, and it's updating in real time, resulting in care that is provided on the 
basis of patient data that is updated in real time. 
[00103] Figure 12 

[00104] In the first step, the Care Management Engine interfaces with Liformation Base, 
Knowledge Base, and DSTs to create Dialogues and Interventions suited to the Patient's 
disease condition. These dialogues and interventions are rendered to the format of the 
communication by rendering engine. Patient replies to query dialogues, Biometric test 
results, and updates of Laboratory and EHRs are fed back into the Information Base. The 
feedback provided from the received data is used to create better decision Support Tools 
that enable better automated processing of patient care. 
[00105] Research Feedback Loop 
[00106] Figure 13, 
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[00107] Research Feedback Loop is primarily used by a researcher to make new 
discoveries and to test hypotheses on the system. Information Base is organized in the 
form of a neural network, thus enabling the Research Engine to scan the data, and to look 
for the correlates in the data, or events that have a greater correlation than can be 
explained by chance alone. These correlates are forwarded to the Researcher, who will 
form a hypothesis. In order to test the hypothesis, the Researcher may use Research 
Engine to interface with Dialogue Engine, and use it to create Dialogues and requests for 
measurements from Biometric Device. The results of the queries and tests measurements 
are forwarded to Information Base, and thence to the Research. Further statistical 
analyses may be performed, and associations may be elicited. For example, the 
Researcher may be able to prove the existence of an unknown factor in a chronic disease 
that causes different people to respond differently to medication. Further correlation with 
molecular and genetic studies may be done to prove or refute the hypothesis. 
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V 



Claims : 

What is claimed is: 
What is claimed is: 

1 . A system for processing medical knowledge, the system comprising: 

a database including medical knowledge sources, wherein an ontology specifies 
how the medical knowledge sources apply to specific disease conditions and patient 
populations; 

a rendering engine to convert medical knowledge obtained from the medical 
knowledge sources to a format suitable for a presentation to a patient on a selected patient 
device; and 

a feedback engine to receive feedback from a plurality of patients and to provide 
feedback data to the database and the knowledge sources. 
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F 



Abstract 

[00108] A . system and method are described for processing medical knowledge. 
The system comprises a database, a rendering engine and a feedback engine. The 
database may include medical knowledge sources, wherein an ontology specifies how the 
medical knowledge sources apply to specific disease conditions and patient populations. 
The rendering engine may convert medical knowledge obtained from the medical 
knowledge sources to a format suitable for a presentation to a patient on a selected patient 
device. The feedback engine may receive feedback from a plurality of patients and to 
provide feedback data to the database and the knowledge sources. 
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